Methods and Apparatus for Unified Inventory and Financial Transaction Management

ABSTRACT

In some embodiments, a system includes one or more computers configured to implement by executing instructions on one or more processors a platform-agnostic transaction-related communication system. The transaction-related communication system includes one or more receiving modules for receiving a first item of financial transaction information from a customer-facing interface, and receiving a second item of financial transaction information from a merchant-facing point-of-sale interface. In some embodiments, the transaction-related communication system includes a point of sale server for rendering in a common internal format the first item of financial transaction information from the customer-facing interface, and rendering in the common internal format the second item of financial transaction information from the merchant-facing point-of-sale interface. In some embodiments, the transaction-related communication system includes a payment processing module for rendering in a second format the first item of financial transaction information for payment processing by a first external financial party.

CLAIM TO PRIORITY

This application further claims benefit of priority of U.S. ProvisionalApplication Ser. No. 62/028,763 entitled “Methods and Apparatus forUnified Inventory and Financial Transaction Management” filed Jul. 24,2014, the content of which is incorporated by reference herein in itsentirety and for all purposes.

This application further claims benefit of priority of U.S. ProvisionalApplication Ser. No. 62/028,933 entitled “Methods and Apparatus forUnified Inventory and Financial Transaction Management” filed Jul. 25,2014, the content of which is incorporated by reference herein in itsentirety and for all purposes.

This application claims benefit of priority of U.S. ProvisionalApplication Ser. No. 62/030,335 entitled “Methods and Apparatus forUnified Inventory Management” filed Jul. 29, 2014, the content of whichis incorporated by reference herein in its entirety and for allpurposes.

This application further claims benefit of priority of U.S. ProvisionalApplication Ser. No. 62/081,329 entitled “Wireless Data CommunicationInterface” filed Nov. 18, 2014, the content of which is incorporated byreference herein in its entirety and for all purposes.

BACKGROUND

1. Description of the Related Art

Electronic commerce, colloquially known as e-commerce or e-business,includes the buying and selling of products or services over electronicsystems such as the Internet and other computer networks. While asignificant percentage of the growth in e-commerce in recent years hasinvolved virtual goods and services, most electronic commerce stillfrequently involves fulfillment of an order through the transportationof physical items in some way and an accompanying financial transaction.In the majority of e-commerce transactions, the purchase transaction isordered or agreed electronically and interactively in real-time andsubsequently completed with the delivery of a physical packagecontaining goods.

The amount of trade conducted electronically has grown rapidly withwidespread Internet usage and has further increased with theproliferation of mobile computing devices capable of accessing theInternet. Such mobile computing devices include laptop computers, tabletcomputers, and handheld telephones.

In today's environment, however, merchants have separate paymentprocessors for their ecommerce, retail stores and mobile sales channelscreating silos of information and disjointed customer experiences. Thereare significant technology roadblocks in the journey to omnichannelcommerce. These roadblocks, or friction points, can hamper a merchant'sability to deploy new sales channels; reach new and existing customerswith relevant, effective promotions and offers; and ultimately expandtheir businesses. In other words, these friction points can prevent abusiness from operating smoothly and reaching its full potential.

These friction points include finding a single payment service providerto process payments across multiple channels. Today, many merchants mustrely on separate payments providers for their in-store, e-commerce andmobile sales.

These friction points include managing product inventory across allchannels of commerce.

SUMMARY

Some embodiments provide a multi-channel (eCommerce, In Store andMobile) payment processing platform with integrated inventory managementand business intelligence providing merchants a single platform toaccept payments, track and manage inventory and gain valuable insightsinto their business performance.

Various embodiments of methods and apparatus for unified inventory andfinancial transaction management are disclosed. Some embodiments includea system for unified inventory and financial transaction management. Insome embodiments, the system includes a processor and programinstructions computer-executable to implement a system for providingpayment processing services from a plurality of disparate paymentprocessors to a plurality of disparate transaction intake platforms. Insome embodiments, the system includes one or more computers configuredto implement by executing instructions on one or more processors aplatform-agnostic transaction-related communication system. In someembodiments, the transaction-related communication system includes oneor more receiving modules for receiving a first item of financialtransaction information from a customer-facing interface, and receivinga second item of financial transaction information from amerchant-facing point-of-sale interface.

In some embodiments, the transaction-related communication systemincludes a point of sale server for rendering in a common internalformat the first item of financial transaction information from thecustomer-facing interface, and rendering in the common internal formatthe second item of financial transaction information from themerchant-facing point-of-sale interface. In some embodiments, thetransaction-related communication system includes a payment processingmodule for rendering in a second format the first item of financialtransaction information for payment processing by a first externalfinancial party, and rendering in a third format the first item offinancial transaction information for payment processing by a secondexternal financial party.

In some embodiments, the transaction-related communication systemincludes a transaction execution module for transmitting in the secondformat the first item of financial transaction information for paymentprocessing by the first external financial party, and transmitting inthe third format the second item of financial transaction informationfor payment processing by the second external financial party.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a distributed system that may implement unifiedinventory and financial transaction management, according to someembodiments.

FIG. 2 depicts a distributed system that may implement unified inventoryand financial transaction management, according to some embodiments.

FIG. 3 depicts a module that may implement unified inventory andfinancial transaction management, according to some embodiments.

FIG. 4 illustrates a module that may implement unified inventory andfinancial transaction management, according to some embodiments.

FIG. 5 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 6 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 7 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 8 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 9 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 10 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 11 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 12 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 13 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments.

FIG. 14 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 15 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 16 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 17 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 18 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 19 is a user interface for selecting for review a sales ticket forunified inventory and financial transaction management, according tosome embodiments.

FIG. 20 is a user interface for reviewing a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 21 is a user interface for selecting for review an item in a salesticket for unified inventory and financial transaction management,according to some embodiments.

FIG. 22 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 23 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 24 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 25 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 26 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 27 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 28 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 29 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 30 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 31 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 32 is a user interface for reviewing an overview of inventory in asystem for unified inventory and financial transaction management,according to some embodiments.

FIG. 33 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 34 is a user interface for recording a transaction in a system forunified inventory and financial transaction management, according tosome embodiments.

FIG. 35 is a user interface for reporting a transaction in a system forunified inventory and financial transaction management, according tosome embodiments.

FIG. 36 is a flowchart of a synchronization method for unified inventoryand financial transaction management, according to some embodiments.

FIG. 37 illustrates an example computer system that may be used inembodiments.

While the invention is described herein by way of example for severalembodiments and illustrative drawings, those skilled in the art willrecognize that the invention is not limited to the embodiments ordrawings described. It should be understood, that the drawings anddetailed description thereto are not intended to limit the invention tothe particular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present invention. The headings used herein arefor organizational purposes only and are not meant to be used to limitthe scope of the description. As used throughout this application, theword “may” is used in a permissive sense (i.e., meaning having thepotential to), rather than the mandatory sense (i.e., meaning must).Similarly, the words “include”, “including”, and “includes” meanincluding, but not limited to.

DETAILED DESCRIPTION OF EMBODIMENTS Brief Introduction to ElectronicCommerce Management for Customized Products

Some embodiments include a system for unified inventory and financialtransaction management. Some embodiments reduce the complications andunnecessary costs of managing payments partnerships across multiplechannels that bring friction into a merchant's business and presentartificial barriers to success. In some embodiments, a system forunified inventory and financial transaction management reduces frictioncaused by disparate processing rates, extra reconciliation paperwork andmisaligned inventory by providing an all-in-one payments solutioncapable, in some embodiments, of receiving data from multiple customertouchpoints across multiple ones of a merchant's channels.

In some embodiments, friction points can be eliminated with theimplementation of a system for unified inventory and financialtransaction management in multiple channels. Some embodiments of asystem for unified inventory and financial transaction management acceptmobile, online and point-of-sale payments under a single merchantaccount, providing room scaling that allows merchants to take advantageof new opportunities for expansion and growth.

Some embodiments of a system for unified inventory and financialtransaction management support a merchant that operates a physicalstore, operates an online store, accepts payments on a mobile device, orany combination of those channels. Some embodiments of a system forunified inventory and financial transaction management present a singlemerchant account to reduce reconciliation and accounting headaches andto provide one version of the data through consolidated reports acrossall channels and touchpoints. Some embodiments of a system for unifiedinventory and financial transaction management can also handle theissues of managing inventory across mobile and e-commerce touchpoints,as well as in the store, providing a single view of the merchandisethat's available to sell, and helping businesses balance betweeninventory and demand.

Some embodiments of a system for unified inventory and financialtransaction management support a cloud-based point-of-sale, mobile andeCommerce framework that integrates payments with inventory management.

Some embodiments of a system for unified inventory and financialtransaction management real-time, in-app inventory tracking, managementand replenishment directly from a mobile application. Some embodimentsof a system for unified inventory and financial transaction managementprovide import and export capabilities that allow merchants to easilytransfer and integrate inventory data into other systems. Someembodiments of a system for unified inventory and financial transactionmanagement provide Integration with third party eCommerceplatforms—sales and inventory data by location provides merchants morevaluable insights into their business. Some embodiments of a system forunified inventory and financial transaction management provide theability to set replenishment thresholds and alerts and transferinventory between locations and channels. Some embodiments of a systemfor unified inventory and financial transaction management adjustinventory for sales and returns in real-time and can also work with amerchant's existing inventory platform, by allowing merchants tointegrate in to some embodiments of a system for unified inventory andfinancial transaction management using application program interfaces.

Some embodiments of a system for unified inventory and financialtransaction management can also solve the problems of the frictionpoints mentioned above by eliminating disparate payment processors andprocessing rates, further simplifying reconciliation across all of amerchant's selling channels. In moving to a single payments providerunder some embodiments, merchants can also take advantage of volumepricing, and get the best possible rates for each channel.

Some embodiments of a system for unified inventory and financialtransaction management provide business insights, such merchants canleverage data to optimize sales, for example such as how much floorspace to allocate to specific products, what items and locations providethe most revenue and profit and what products to feature. Merchants alsohave the ability to store customer history, past purchases and othercustomer-specific data to help them become more customer-centric. Thesesystems open the door to integrated loyalty programs and other customerrelationship management tools to help merchants know who their bestcustomers are and how to best reach them how, when and where thecustomer wants to shop.

Some embodiments of a system for unified inventory and financialtransaction management also allow developers to integrate payments,inventory and business insights into their platforms through the onlysingle stack of application program interfaces for card present and cardnot present transactions.

In some embodiments, the system includes a processor and programinstructions computer-executable to implement a system for providingpayment processing services from a plurality of disparate paymentprocessors to a plurality of disparate transaction intake platforms. Insome embodiments, the system includes one or more computers configuredto implement by executing instructions on one or more processors aplatform-agnostic transaction-related communication system. In someembodiments, the transaction-related communication system includes oneor more receiving modules for receiving a first item of financialtransaction information from a customer-facing interface, and receivinga second item of financial transaction information from amerchant-facing point-of-sale interface.

In some embodiments, the transaction-related communication systemincludes a point of sale server for rendering in a common internalformat the first item of financial transaction information from thecustomer-facing interface, and rendering in the common internal formatthe second item of financial transaction information from themerchant-facing point-of-sale interface. In some embodiments, thetransaction-related communication system includes a payment processingmodule for rendering in a second format the first item of financialtransaction information for payment processing by a first externalfinancial party, and rendering in a third format the first item offinancial transaction information for payment processing by a secondexternal financial party.

In some embodiments, the transaction-related communication systemincludes a transaction execution module for transmitting in the secondformat the first item of financial transaction information for paymentprocessing by the first external financial party, and transmitting inthe third format the second item of financial transaction informationfor payment processing by the second external financial party.

In some embodiments, the system supports providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms. In some embodiments, thecommon internal format is a common intake transaction ticket format. Insome embodiments, the one or more receiving modules include a singlestack application program interface residing on one of the one or moreservers. In some embodiments, the receiving the first item of financialtransaction information from the customer-facing interface furtherincludes receiving in the common intake transaction ticket format overthe network from a mobile computing device the first item of financialtransaction information from the customer-facing interface. In someembodiments, the receiving the second item of financial transactioninformation from the merchant-facing point-of-sale interface furtherincludes receiving over the network in the common intake transactionticket format the second item of financial transaction information fromthe merchant-facing point-of-sale interface.

In some embodiments, the common internal format is a common intaketransaction ticket format. In some embodiments, the system furtherincludes a first translation module on a mobile computing device forreceiving from a customer facing application including thecustomer-facing interface on the mobile computing device the first itemof financial transaction information, and translating to a common intaketransaction ticket format the first item of financial transactioninformation. In some embodiments, the system further includes a secondtranslation module on a merchant-facing point of sale device forreceiving from a merchant facing application including themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, andtranslating to the common intake transaction ticket format the seconditem of financial transaction information.

In some embodiments, the one or more receiving modules include a singlestack application program interface residing on one of the one or moreservers. In some embodiments, the server communicates remotely with themobile computing device over a wireless network. In some embodiments,the server communicates remotely with the merchant-facing point of saledevice over a second network. In some embodiments, the receiving thefirst item of financial transaction information from the customer-facinginterface further includes receiving in the common intake transactionticket format at the single stack application interface from the mobilecomputing device the first item of financial transaction informationfrom the customer-facing interface. In some embodiments, the receivingthe second item of financial transaction information from themerchant-facing point-of-sale interface further includes receiving inthe common intake transaction ticket format at the single stackapplication interface the second item of financial transactioninformation from the merchant-facing point-of-sale interface.

In some embodiments, the transaction execution module is furtherconfigured for receiving on the one or more servers a transactionauthorization confirmation from the first external financial party, andthe point of sale server is further configured for transmitting to thecustomer-facing interface an indication of the transaction authorizationconfirmation. In some embodiments, the payment processing moduleincludes a payment processing gateway for communicating with servers ofexternal financial processors using encrypted links over a network.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms further includes a businessintelligence analytics module for providing business intelligence basedat least in part on the first item of financial transaction information.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms further includes an inventorycoordination module for providing transaction fulfillment informationbased at least in part on the first item of financial transactioninformation.

Some embodiments include a method for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms. In some embodiments, themethod includes causing modules, implemented as hardware, software, or acombination of hardware and software on one or more computers executinginstructions on one or more processors to implement a platform-agnostictransaction-related communication system that performs a methodincluding receiving a first item of financial transaction informationfrom a customer-facing interface and receiving a second item offinancial transaction information from a merchant-facing point-of-saleinterface.

In some embodiments, the method includes rendering in a common internalformat the first item of financial transaction information from thecustomer-facing interface. In some embodiments, the method includesrendering in the common internal format the second item of financialtransaction information from the merchant-facing point-of-saleinterface. In some embodiments, the method includes rendering in asecond format the first item of financial transaction information forpayment processing by a first external financial party. In someembodiments, the method includes rendering in a third format the firstitem of financial transaction information for payment processing by asecond external financial party.

In some embodiments, the method includes transmitting in the secondformat the first item of financial transaction information for paymentprocessing by the first external financial party. In some embodiments,the method includes transmitting in the third format the second item offinancial transaction information for payment processing by the secondexternal financial party.

In some embodiments, the method includes providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms. In some embodiments, thecommon internal format is a common intake transaction ticket format.

In some embodiments, the receiving the first item of financialtransaction information from the customer-facing interface furtherincludes receiving in the common intake transaction ticket format overthe network from a mobile computing device the first item of financialtransaction information from the customer-facing interface. In someembodiments, the receiving the second item of financial transactioninformation from the merchant-facing point-of-sale interface furtherincludes receiving over the network in the common intake transactionticket format the second item of financial transaction information fromthe merchant-facing point-of-sale interface.

In some embodiments, the common internal format is a common intaketransaction ticket format, and the method further includes receivingfrom a customer facing application including the customer-facinginterface on the mobile computing device the first item of financialtransaction information. In some embodiments, the common internal formatis a common intake transaction ticket format, and the method furtherincludes translating to a common intake transaction ticket format thefirst item of financial transaction information. In some embodiments,the common internal format is a common intake transaction ticket format,and the method further includes receiving from a merchant facingapplication including the merchant-facing point-of-sale interface on amerchant point of sale device the second item of financial transactioninformation. In some embodiments, the common internal format is a commonintake transaction ticket format, and the method further includestranslating to the common intake transaction ticket format the seconditem of financial transaction information.

In some embodiments, the receiving the first item of financialtransaction information from the customer-facing interface furtherincludes receiving in the common intake transaction ticket format at asingle stack application interface from the mobile computing device thefirst item of financial transaction information from the customer-facinginterface. In some embodiments, the receiving the second item offinancial transaction information from the merchant-facing point-of-saleinterface further includes receiving in the common intake transactionticket format at the single stack application interface the second itemof financial transaction information from the merchant-facingpoint-of-sale interface.

In some embodiments, the method further includes receiving on the one ormore servers a transaction authorization confirmation from the firstexternal financial party, and transmitting to the customer-facinginterface an indication of the transaction authorization confirmation.In some embodiments, the method further includes a payment processinggateway communicating with servers of external financial processorsusing encrypted links over a network. In some embodiments, the methodfurther includes a business intelligence analytics module providingbusiness intelligence based at least in part on the first item offinancial transaction information.

In some embodiments, the method further includes an inventorycoordination module providing transaction fulfillment information basedat least in part on the first item of financial transaction information.

Some embodiments include a non-transitory computer-readable storagemedium storing program instructions for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms. In some embodiments, theprogram instructions are computer-executable to implement receiving afirst item of financial transaction information from a customer-facinginterface. In some embodiments, the program instructions arecomputer-executable to implement receiving a second item of financialtransaction information from a merchant-facing point-of-sale interface.In some embodiments, the program instructions are computer-executable toimplement rendering in a common internal format the first item offinancial transaction information from the customer-facing interface. Insome embodiments, the program instructions are computer-executable toimplement rendering in the common internal format the second item offinancial transaction information from the merchant-facing point-of-saleinterface.

In some embodiments, the program instructions are computer-executable toimplement transmitting in the second format the first item of financialtransaction information for payment processing by the first externalfinancial party. In some embodiments, the program instructions arecomputer-executable to implement transmitting in the third format thesecond item of financial transaction information for payment processingby the second external financial party.

In some embodiments, the common internal format is a common intaketransaction ticket format. In some embodiments, the program instructionscomputer-executable to implement receiving the first item of financialtransaction information from the customer-facing interface furtherinclude program instructions computer-executable to implement receivingin the common intake transaction ticket format over the network from amobile computing device the first item of financial transactioninformation from the customer-facing interface. In some embodiments, theprogram instructions computer-executable to implement receiving thesecond item of financial transaction information from themerchant-facing point-of-sale interface further include programinstructions computer-executable to implement receiving over the networkin the common intake transaction ticket format the second item offinancial transaction information from the merchant-facing point-of-saleinterface.

In some embodiments, the common internal format is a common intaketransaction ticket format. In some embodiments, the program instructionscomputer-executable for providing payment processing services furtherinclude program instructions computer-executable to implement receivingfrom a customer facing application including the customer-facinginterface on the mobile computing device the first item of financialtransaction information. In some embodiments, the program instructionscomputer-executable for providing payment processing services furtherinclude program instructions computer-executable to implementtranslating to a common intake transaction ticket format the first itemof financial transaction information. In some embodiments, the programinstructions for providing payment processing services further includeprogram instructions computer-executable to implement receiving from amerchant facing application including the merchant-facing point-of-saleinterface on a merchant point of sale device the second item offinancial transaction information. In some embodiments, the programinstructions for providing payment processing services further includeprogram instructions computer-executable to implement translating to thecommon intake transaction ticket format the second item of financialtransaction information.

In some embodiments, the one or more receiving modules include a singlestack application program interface residing on one of the one or moreservers. In some embodiments, the program instructionscomputer-executable to implement receiving the first item of financialtransaction information from the customer-facing interface furtherinclude program instructions computer-executable to implement receivingin the common intake transaction ticket format at the single stackapplication interface from the mobile computing device the first item offinancial transaction information from the customer-facing interface. Insome embodiments, the program instructions computer-executable toimplement receiving the second item of financial transaction informationfrom the merchant-facing point-of-sale interface further include programinstructions computer-executable to implement receiving in the commonintake transaction ticket format at the single stack applicationinterface the second item of financial transaction information from themerchant-facing point-of-sale interface.

In some embodiments, the program instructions for providing paymentprocessing services further include program instructionscomputer-executable to implement receiving on the one or more servers atransaction authorization confirmation from the first external financialparty, and program instructions computer-executable to implementtransmitting to the customer-facing interface an indication of thetransaction authorization confirmation. In some embodiments, the programinstructions for providing payment processing services further includeprogram instructions computer-executable to implement further includeprogram instructions computer-executable to implement a paymentprocessing gateway for communicating with servers of external financialprocessors using encrypted links over a network.

In some embodiments, the program instructions for providing paymentprocessing services further include program instructionscomputer-executable to implement program instructionscomputer-executable to implement a business intelligence analyticsmodule for providing business intelligence based at least in part on thefirst item of financial transaction information. In some embodiments,the program instructions for providing payment processing servicesfurther include program instructions computer-executable to implementprogram instructions computer-executable to implement an inventorycoordination module for transaction fulfillment information based atleast in part on the first item of financial transaction information.

Example Implementations

FIG. 1 illustrates a distributed system that may implement unifiedinventory and financial transaction management, according to someembodiments. An integrated electronic commerce management provider 100manages a system 198 for providing payment processing services from aplurality of disparate payment processors 152-156 to a plurality ofdisparate transaction intake platforms 110 and 120. Integratedelectronic commerce management provider 100 includes, in someembodiments, a database 102 storing electronic commerce inventory andtransaction records in a common internal format. Integrated electroniccommerce management provider 100 includes, in some embodiments, anintegrated electronic commerce module 104 for implementingplatform-agnostic transaction-related communication across a clientinterface 106. An ordering customer client 110, a merchant client 120,payment processors 152-156, a point of sale location 160, an inventoryresource 170, and another point of sale location 180 communicate acrossnetwork 150 with integrated electronic commerce module 104 to implementplatform-agnostic transaction-related communication using clientinterface 106.

On ordering customer client 110, a customer-facing order interface 112transmits and receives transaction information (in some embodimentseither or both financial and inventory) as communications 114 withclient interface 106 over network 150. On merchant client 120, amerchant interface 122 transmits and receives transaction information(in some embodiments either or both financial and inventory) ascommunications 124 with client interface 106 over network 150. Paymentprocessors 152-156 transmit and receive transaction communications164-168 with client interface 106 over network 150.

In some embodiments, inventory transactions can be reported by orordered by transaction communication 104 a-104 n over network 150 topoint of sale client 162, inventory client 172, and point of sale client182. In some embodiments, inventory transactions involve the delivery194 or return 192 of delivery goods 190. Likewise, inventorytransactions involve the transfer 184 from a first point of salelocation 180 to a second point of sale location 160 or the transfer 174from an inventory resource 170 to a point of sale location 160.

In some embodiments, the system 198 includes one or more computers, suchas will be discussed below with respect to FIG. 36, configured toimplement by executing instructions on one or more processors aplatform-agnostic transaction-related communication system. In someembodiments, the transaction-related communication system includes oneor more receiving modules, which can, in some example embodiments, belocated in ordering customer client 110, merchant client 120, orintegrated electronic commerce module 104, for receiving a first item offinancial transaction information from a customer-facing interface (forexample, in some embodiments order interface 112), and receiving asecond item of financial transaction information from a merchant-facingpoint-of-sale interface (for example, in some embodiments merchantinterface 122). As one of skill in the art will readily comprehend inlight of having read the present disclosure, any function described ashaving been performed by a module or interface of the present disclosurecan be performed by another interface or module of the presentdisclosure without departing from the scope and intent of the presentdisclosure.

In some embodiments, the transaction-related communication systemincludes a point of sale server (for example, in some embodimentslocated in ordering customer client 110) for rendering in a commoninternal format the first item of financial transaction information fromthe customer-facing interface (for example, in some embodiments orderinterface 112), and rendering in the common internal format the seconditem of financial transaction information from the merchant-facingpoint-of-sale interface (for example, in some embodiments merchantinterface 122). In some embodiments, the transaction-relatedcommunication system includes a payment processing module (for example,in some embodiments, contained within integrated electronic commercemodule 104), for rendering in a second format the first item offinancial transaction information for payment processing by a firstexternal financial party (for example, in some embodiments paymentprocessor 152), and rendering in a third format the first item offinancial transaction information for payment processing by a secondexternal financial party (for example, in some embodiments paymentprocessor 154).

In some embodiments, the transaction-related communication systemincludes a transaction execution module (for example, in someembodiments, contained within integrated electronic commerce module104), for transmitting in the second format the first item of financialtransaction information for payment processing by the first externalfinancial party (for example, in some embodiments payment processor152), and transmitting in the third format the second item of financialtransaction information for payment processing by the second externalfinancial party (for example, in some embodiments payment processor154).

In some embodiments, the system provides payment processing servicesfrom a plurality of disparate payment processors (for example, in someembodiments, payment processors 154-156) to a plurality of disparatetransaction intake platforms (for example, in some embodiments orderingcustomer client 110 and merchant client 120). In some embodiments, thecommon internal format is a common intake transaction ticket format. Insome embodiments, the one or more receiving modules include a singlestack application program interface residing on one of the one or moreservers (for example, in some embodiments as a part of client interface106). In some embodiments, the receiving the first item of financialtransaction information from the customer-facing interface (for example,in some embodiments order interface 112) further includes receiving inthe common intake transaction ticket format over the network from amobile computing device (for example, in some embodiments orderingclient 110) the first item of financial transaction information from thecustomer-facing interface (for example, in some embodiments orderinterface 112). In some embodiments, the receiving the second item offinancial transaction information from the merchant-facing point-of-saleinterface (for example, in some embodiments merchant interface 122)further includes receiving over the network in the common intaketransaction ticket format the second item of financial transactioninformation from the merchant-facing point-of-sale interface (forexample, in some embodiments merchant client 120).

In some embodiments, the common internal format is a common intaketransaction ticket format. In some embodiments, the system furtherincludes a first translation module on a mobile computing device (forexample, in some embodiments ordering customer client 120) for receivingfrom a customer facing application including the customer-facinginterface (for example, in some embodiments order interface 112) on themobile computing device the first item of financial transactioninformation, and translating to a common intake transaction ticketformat the first item of financial transaction information. In someembodiments, the system further includes a second translation module ona merchant-facing point of sale device (for example, in some embodimentsmerchant client 120) for receiving from a merchant facing application(for example, in some embodiments merchant interface 122) including themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, andtranslating to the common intake transaction ticket format the seconditem of financial transaction information.

In some embodiments, the one or more receiving modules include a singlestack application program interface residing on one of the one or moreservers (for example, in some embodiments in client interface 112). Insome embodiments, the server (for example, in some embodimentsintegrated electronic commerce module 104) communicates (for example, insome embodiments sending and receiving communications 114) remotely withthe mobile computing device (for example, in some embodiments customerordering client 110) over a wireless network (for example, in someembodiments network 150). In some embodiments, the server (for example,in some embodiments integrated electronic commerce module 104)communicates remotely with the merchant-facing point of sale device overa second network. In some embodiments, the receiving the first item offinancial transaction information from the customer-facing interface(for example, in some embodiments in order interface 112) furtherincludes receiving in the common intake transaction ticket format at thesingle stack application interface (for example, in some embodiments inclient interface 106) from the mobile computing device the first item offinancial transaction information from the customer-facing interface(for example, in some embodiments in ordering interface 112). In someembodiments, the receiving the second item of financial transactioninformation from the merchant-facing point-of-sale interface furtherincludes receiving in the common intake transaction ticket format at thesingle stack application interface (for example, in some embodiments inclient interface 106) the second item of financial transactioninformation from the merchant-facing point-of-sale interface (forexample, in some embodiments merchant interface 122).

In some embodiments, the transaction execution module (for example, insome embodiments in integrated electronic commerce module 104) isfurther configured for receiving on the one or more servers atransaction authorization confirmation from the first external financialparty, and the point of sale server (for example, in some embodiments inintegrated electronic commerce module 104) is further configured fortransmitting to the customer-facing interface (for example, in someembodiments order interface 112) an indication of the transactionauthorization confirmation. In some embodiments, the payment processingmodule includes a payment processing gateway (for example, in someembodiments in client interface 106) for communicating with servers ofexternal financial processors (for example, in some embodiments paymentprocessors 152-156) using encrypted links over a network 150.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors (for example,in some embodiments payment processors 152-156) to a plurality ofdisparate transaction intake platforms further includes a businessintelligence analytics module (for example, in some embodiments inintegrated electronic commerce module 104) for providing businessintelligence based at least in part on the first item of financialtransaction information.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors (for example,in some embodiments payment processors 152-156) to a plurality ofdisparate transaction intake platforms (for example, in some embodimentsmerchant client 120 and ordering customer client 110) further includesan inventory coordination module (for example, in some embodiments inintegrated electronic commerce module 104) for providing transactionfulfillment information based at least in part on the first item offinancial transaction information.

In some embodiments, the inventory coordination module enables theintegrated electronic commerce module 104 to monitor consolidated stocklevels and determine when to re-order, without relying on additionalsystems or manual reporting, thereby enabling merchants to provide aconsistent, seamless experience for consumers across all channels,including offering returns through any channel no matter where thepurchase originated. Some embodiments of integrated electronic commercemodule 104 support a merchant that operates a physical store, operatesan online store, accepts payments on a mobile device, or any combinationof those channels. Some embodiments of integrated electronic commercemodule 104 present a single merchant account to reduce reconciliationand accounting headaches and to provide one version of the data throughconsolidated reports across all channels and touchpoints. Someembodiments of integrated electronic commerce module 104 can also handlethe issues of managing inventory across mobile and e-commercetouchpoints, as well as in the store, providing a single view of themerchandise that's available to sell, and helping businesses balancebetween inventory and demand.

Some embodiments of integrated electronic commerce module 104 support acloud-based point-of-sale, mobile and eCommerce framework thatintegrates payments with inventory management.

Some embodiments of integrated electronic commerce module 104 real-time,in-app inventory tracking, management and replenishment directly from amobile application. Some embodiments of integrated electronic commercemodule 104 provide import and export capabilities that allow merchantsto easily transfer and integrate inventory data into other systems. Someembodiments of integrated electronic commerce module 104 provideIntegration with third party eCommerce platforms—sales and inventorydata by location provides merchants more valuable insights into theirbusiness.

Some embodiments of integrated electronic commerce module 104 providethe ability to set replenishment thresholds and alerts and transferinventory between locations and channels. Some embodiments of integratedelectronic commerce module 104 adjust inventory for sales and returns inreal-time and can also work with a merchant's existing inventoryplatform, by allowing merchants to integrate in to some embodiments ofintegrated electronic commerce module 104 using application programinterfaces.

Some embodiments of integrated electronic commerce module 104 can alsosolve the problems of the friction points mentioned above by eliminatingdisparate payment processors and processing rates, further simplifyingreconciliation across all of a merchant's selling channels. In moving toa single payments provider under some embodiments, merchants can alsotake advantage of volume pricing, and get the best possible rates foreach channel.

Some embodiments of integrated electronic commerce module 104 providebusiness insights, such merchants can leverage data to optimize sales,for example such as how much floor space to allocate to specificproducts, what items and locations provide the most revenue and profitand what products to feature. Merchants also have the ability to storecustomer history, past purchases and other customer-specific data tohelp them become more customer-centric. These systems open the door tointegrated loyalty programs and other customer relationship managementtools to help merchants know who their best customers are and how tobest reach them how, when and where the customer wants to shop.

Some embodiments of integrated electronic commerce module 104 also allowdevelopers to integrate payments, inventory and business insights intotheir platforms through the only single stack of application programinterfaces for card present and card not present transactions.

FIG. 2 depicts a distributed system that may implement unified inventoryand financial transaction management, according to some embodiments. Anintegrated electronic commerce management provider 200 hosts a system298 for providing payment processing services from a plurality ofdisparate payment processors 252-256 to a plurality of disparatetransaction intake platforms 218, 210 and 220. Integrated electroniccommerce management provider 200 includes, in some embodiments, adatabase 202 storing electronic commerce inventory and transactionrecords in a common internal format. Integrated electronic commercemanagement provider 200 includes, in some embodiments, an integratedelectronic commerce module 204 for implementing platform-agnostictransaction-related communication across a single-stack standardapplication program interface gateway 206. An ordering customer clientembodied in the form of a customer mobile device 210, a merchant clientembodied in the form of a cash register or other form of merchant-facingpoint of sale hardware 220, a customer web browser 218, paymentprocessors 252-256, a point of sale location embodied as abrick-and-mortar store 260, an inventory resource embodied as afulfillment warehouse 270, and another point of sale location embodiedas a brick-and-mortar store 280 communicate across network 250 withintegrated electronic commerce module 204 to implement platform-agnostictransaction-related communication using single-stack standardapplication program interface gateway 206.

On customer mobile device 210, a customer-facing an order interfaceembodied as a customer-facing mobile point of sale application 212undertakes transaction communications 214 with single-stack standardapplication program interface gateway 206 over network 250. On customerweb browser 218 (e.g., executing on a desktop PC), a customer-facing anorder interface embodied as a customer-facing web interface 216undertakes transaction communications 215 with single-stack standardapplication program interface gateway 206 over network 250. Onmerchant-facing point-of-sale hardware client 220, a merchant point ofsale interface 222 undertakes transaction communications 224 withsingle-stack standard application program interface gateway 206 overnetwork 250. Payment processors 252-256 undertake transactioncommunications 264-268 with single-stack standard application programinterface gateway 206 over network 250. In some embodiments, wirelesstransaction communications 296 are undertaken between customer mobiledevice 210 and merchant-facing point of sale hardware 220 to automatecreation of transactions.

In some embodiments, inventory transactions can be reported by orordered by transaction communication 204 a-204 n over network 250 topoint of sale client 262, inventory client 272, and point of sale client282. In some embodiments, inventory transactions involve the delivery294 or return 292 of delivery goods 290. Likewise, inventorytransactions involve the transfer 284 from a first point of salelocation in the form of second brick and mortar store 280 to a secondpoint of sale location in the form of first brick and mortar store 260or the transfer 274 from an inventory resource in the form offulfillment warehouse 270 to a point of sale location in the form offirst brick and mortar store 260.

In some embodiments, the system 298 includes one or more computers, suchas will be discussed below with respect to FIG. 36, configured toimplement by executing instructions on one or more processors aplatform-agnostic transaction-related communication system. In someembodiments, the transaction-related communication system includes oneor more receiving modules, which can, in some example embodiments, belocated in or executing on customer web browser 218, customer mobiledevice 210, merchant facing point of sale hardware 220, or integratedelectronic commerce module 204, for receiving a first item of financialtransaction information from a customer-facing interface (for example,in some embodiments customer facing mobile point of sale application 212or customer facing web interface 216), and receiving a second item offinancial transaction information from a merchant-facing point-of-saleinterface (for example, in some embodiments merchant point of saleinterface 222). As one of skill in the art will readily comprehend inlight of having read the present disclosure, any function described ashaving been performed by a module or interface of the present disclosurecan be performed by another interface or module of the presentdisclosure without departing from the scope and intent of the presentdisclosure.

In some embodiments, the transaction-related communication systemincludes a point of sale server (for example, in some embodimentslocated in customer mobile device 210) for rendering in a commoninternal format the first item of financial transaction information fromthe customer-facing interface (for example, in some embodiments customerfacing mobile point of sale application 212), and rendering in thecommon internal format the second item of financial transactioninformation from the merchant-facing point-of-sale interface (forexample, in some embodiments merchant point of sale interface 222). Insome embodiments, the transaction-related communication system includesa payment processing module (for example, in some embodiments, containedwithin integrated electronic commerce module 204), for rendering in asecond format the first item of financial transaction information forpayment processing by a first external financial party (for example, insome embodiments payment processor 252), and rendering in a third formatthe first item of financial transaction information for paymentprocessing by a second external financial party (for example, in someembodiments payment processor 254).

In some embodiments, the transaction-related communication systemincludes a transaction execution module (for example, in someembodiments, contained within integrated electronic commerce module204), for transmitting in the second format the first item of financialtransaction information for payment processing by the first externalfinancial party (for example, in some embodiments payment processor252), and transmitting in the third format the second item of financialtransaction information for payment processing by the second externalfinancial party (for example, in some embodiments payment processor254).

In some embodiments, the system provides payment processing servicesfrom a plurality of disparate payment processors (for example, in someembodiments, payment processors 252-256) to a plurality of disparatetransaction intake platforms (for example, in some embodiments customermobile device 210 and merchant facing point of sale hardware 220). Insome embodiments, the common internal format is a common intaketransaction ticket format. In some embodiments, the one or morereceiving modules include a single stack application program interfaceresiding on one of the one or more servers (for example, in someembodiments as a part of single-stack standard application programminginterface gateway 206). In some embodiments, the receiving the firstitem of financial transaction information from the customer-facinginterface (for example, in some embodiments customer facing mobile pointof sale application 212) further includes receiving in the common intaketransaction ticket format over the network from a mobile computingdevice (for example, in some embodiments customer mobile device 210 orcustomer web browser 218) the first item of financial transactioninformation from the customer-facing interface (for example, in someembodiments customer facing mobile point of sale application 212). Insome embodiments, the receiving the second item of financial transactioninformation from the merchant-facing point-of-sale interface (forexample, in some embodiments merchant point of sale interface 222)further includes receiving over the network in the common intaketransaction ticket format the second item of financial transactioninformation from the merchant-facing point-of-sale interface (forexample, in some embodiments merchant facing point of sale hardware220).

In some embodiments, the common internal format is a common intaketransaction ticket format. In some embodiments, the system furtherincludes a first translation module on a mobile computing device (forexample, in some embodiments customer mobile device 210) for receivingfrom a customer facing application including the customer-facinginterface (for example, in some embodiments customer facing mobile pointof sale application 212) on the mobile computing device the first itemof financial transaction information, and translating to a common intaketransaction ticket format the first item of financial transactioninformation. In some embodiments, the system further includes a secondtranslation module on a merchant-facing point of sale device (forexample, in some embodiments merchant facing point of sale hardware 220)for receiving from a merchant facing application (for example, in someembodiments merchant point of sale interface 222) including themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, andtranslating to the common intake transaction ticket format the seconditem of financial transaction information.

In some embodiments, the one or more receiving modules include a singlestack application program interface residing on one of the one or moreservers. In some embodiments, the server (for example, in someembodiments integrated electronic commerce module 204) communicates (forexample, in some embodiments sending and receiving communications 214)remotely with the mobile computing device (for example, in someembodiments customer mobile device 210) over a wireless network (forexample, in some embodiments network 250). In some embodiments, theserver (for example, in some embodiments integrated electronic commercemodule 204) communicates remotely with the merchant-facing point of saledevice over a second network. In some embodiments, the receiving thefirst item of financial transaction information from the customer-facinginterface (for example, in some embodiments in customer facing mobilepoint of sale application 212) further includes receiving in the commonintake transaction ticket format at the single stack applicationinterface (for example, in some embodiments in single-stack standardapplication programming interface gateway 206) from the mobile computingdevice the first item of financial transaction information from thecustomer-facing interface (for example, in some embodiments incustomer-facing mobile point of sale application 212). In someembodiments, the receiving the second item of financial transactioninformation from the merchant-facing point-of-sale interface furtherincludes receiving in the common intake transaction ticket format at thesingle stack application interface (for example, in some embodiments insingle-stack standard application programming interface gateway 206) thesecond item of financial transaction information from themerchant-facing point-of-sale interface (for example, in someembodiments merchant point of sale interface 222).

In some embodiments, the transaction execution module (for example, insome embodiments in integrated electronic commerce module 204) isfurther configured for receiving on the one or more servers atransaction authorization confirmation from the first external financialparty, and the point of sale server (for example, in some embodiments inintegrated electronic commerce module 204) is further configured fortransmitting to the customer-facing interface (for example, in someembodiments customer facing mobile point of sale application 212) anindication of the transaction authorization confirmation. In someembodiments, the payment processing module includes a payment processinggateway (for example, in some embodiments in single-stack standardapplication programming interface gateway 206) for communicating withservers of external financial processors (for example, in someembodiments payment processors 252-256) using encrypted links over anetwork 250.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors (for example,in some embodiments payment processors 252-256) to a plurality ofdisparate transaction intake platforms further includes a businessintelligence analytics module (for example, in some embodiments inintegrated electronic commerce module 204) for providing businessintelligence based at least in part on the first item of financialtransaction information.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors (for example,in some embodiments payment processors 252-256) to a plurality ofdisparate transaction intake platforms (for example, in some embodimentsmerchant facing point of sale hardware 220 and customer mobile device210) further includes an inventory coordination module (for example, insome embodiments in integrated electronic commerce module 204) forproviding transaction fulfillment information based at least in part onthe first item of financial transaction information.

In some embodiments, the inventory coordination module enables theintegrated electronic commerce module 204 to monitor consolidated stocklevels and determine when to re-order, without relying on additionalsystems or manual reporting, thereby enabling merchants to provide aconsistent, seamless experience for consumers across all channels,including offering returns through any channel no matter where thepurchase originated.

Some embodiments of integrated electronic commerce module 204 support amerchant that operates a physical store, operates an online store,accepts payments on a mobile device, or any combination of thosechannels. Some embodiments of integrated electronic commerce module 204present a single merchant account to reduce reconciliation andaccounting headaches and to provide one version of the data throughconsolidated reports across all channels and touchpoints. Someembodiments of integrated electronic commerce module 204 can also handlethe issues of managing inventory across mobile and e-commercetouchpoints, as well as in the store, providing a single view of themerchandise that's available to sell, and helping businesses balancebetween inventory and demand.

Some embodiments of integrated electronic commerce module 204 support acloud-based point-of-sale, mobile and eCommerce framework thatintegrates payments with inventory management.

Some embodiments of integrated electronic commerce module 204 real-time,in-app inventory tracking, management and replenishment directly from amobile application. Some embodiments of integrated electronic commercemodule 204 provide import and export capabilities that allow merchantsto easily transfer and integrate inventory data into other systems. Someembodiments of integrated electronic commerce module 204 provideIntegration with third party eCommerce platforms—sales and inventorydata by location provides merchants more valuable insights into theirbusiness. Some embodiments of integrated electronic commerce module 204provide the ability to set replenishment thresholds and alerts andtransfer inventory between locations and channels. Some embodiments ofintegrated electronic commerce module 204 adjust inventory for sales andreturns in real-time and can also work with a merchant's existinginventory platform, by allowing merchants to integrate in to someembodiments of integrated electronic commerce module 204 usingapplication program interfaces.

Some embodiments of integrated electronic commerce module 204 can alsosolve the problems of the friction points mentioned above by eliminatingdisparate payment processors and processing rates, further simplifyingreconciliation across all of a merchant's selling channels. In moving toa single payments provider under some embodiments, merchants can alsotake advantage of volume pricing, and get the best possible rates foreach channel.

Some embodiments of integrated electronic commerce module 204 providebusiness insights, such merchants can leverage data to optimize sales,for example such as how much floor space to allocate to specificproducts, what items and locations provide the most revenue and profitand what products to feature. Merchants also have the ability to storecustomer history, past purchases and other customer-specific data tohelp them become more customer-centric. These systems open the door tointegrated loyalty programs and other customer relationship managementtools to help merchants know who their best customers are and how tobest reach them how, when and where the customer wants to shop.

Some embodiments of integrated electronic commerce module 204 also allowdevelopers to integrate payments, inventory and business insights intotheir platforms through the only single stack of application programinterfaces for card present and card not present transactions.

FIG. 3 depicts a module that may implement unified inventory andfinancial transaction management, according to some embodiments. Anelectronic commerce management module 320 receives as input transactionexecution confirmations 370 transaction tickets 310 and user input 312(for example, in some embodiments, through a user interface 322) andstores transaction execution orders 350, unified inventory data 330, andunified format transactions 360 in a storage medium 340. Electroniccommerce management module 320 is one embodiment of integratedelectronic commerce module 104 of FIG. 1, which is discussed above.

In some embodiments, electronic commerce management module 320 includesa transaction intake module 324, an inventory coordination module 326, asynchronization server module 336, a financial execution module 334, abusiness intelligence analytics module 328, and an advertising module332.

In some embodiments, electronic commerce management module 320implements or supports a system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms. In some embodiments,electronic commerce management module 320 includes one or more computersconfigured to implement by executing instructions on one or moreprocessors a platform-agnostic transaction-related communication system.In some embodiments, electronic commerce management module 320 includessoftware for execution on one or more computers configured to implementby executing instructions on one or more processors a platform-agnostictransaction-related communication system. In some embodiments, thetransaction-related communication system includes one or more receivingmodules, such as transaction intake module 324, for receiving a firstitem of financial transaction information from a customer-facinginterface, such as a user interface 322, which may be implemented onelectronic commerce management module 320 or in a separate system, andreceiving a second item of financial transaction information from amerchant-facing point-of-sale interface.

In some embodiments, the transaction-related communication systemincludes a point of sale server, for example as a component of financialexecution module 334, for rendering in a common internal format (forexample, for storage on storage medium 340 as unified formattransactions 360) the first item of financial transaction informationfrom the customer-facing interface of user interface 322, and renderingin the common internal format (for example, for storage on storagemedium 340 as unified format transactions 360) the second item offinancial transaction information from the merchant-facing point-of-saleinterface. In some embodiments, the transaction-related communicationsystem includes a payment processing module, for example as a componentof financial execution module 334, for rendering in a second format (forexample, as transaction execution orders 350) the first item offinancial transaction information for payment processing by a firstexternal financial party, and rendering in a third format (for example,as transaction execution orders 350) the first item of financialtransaction information for payment processing by a second externalfinancial party.

In some embodiments, the transaction-related communication systemincludes a transaction execution module, for example as a component offinancial execution module 334, for transmitting in the second formatthe first item of financial transaction information for paymentprocessing by the first external financial party, and transmitting inthe third format the second item of financial transaction informationfor payment processing by the second external financial party.

In some embodiments, the system uses electronic commerce managementmodule 320 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms. In some embodiments, the common internal format is acommon intake transaction ticket format, which may be used in unifiedformat transactions 360. In some embodiments, the one or more receivingmodules, such as transaction intake module 324, include a single stackapplication program interface residing on one of the one or more serversthat host or comprise electronic commerce management module 320. In someembodiments, the receiving the first item of financial transactioninformation, such as transaction tickets 310, from a customer-facinginterface further includes receiving in the common intake transactionticket format over the network from a mobile computing device the firstitem of financial transaction information from the customer-facinginterface, such as a user interface 322 implemented on a system remotefrom electronic commerce management module 320. In some embodiments, thereceiving the second item of financial transaction information, such astransaction tickets 310, from the merchant-facing point-of-saleinterface further includes receiving over the network in the commonintake transaction ticket format the second item of financialtransaction information from the merchant-facing point-of-saleinterface.

In some embodiments, the common internal format is a common intaketransaction ticket format for use in transaction tickets 310. In someembodiments, the system further includes a first translation module on amobile computing device, such as a user interface 322 implemented on asystem remote from electronic commerce management module 320, forreceiving from a customer facing application including thecustomer-facing interface on the mobile computing device the first itemof financial transaction information, and translating to a common intaketransaction ticket format the first item of financial transactioninformation. In some embodiments, the system further includes a secondtranslation module on a merchant-facing point of sale device forreceiving from a merchant facing application including themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, andtranslating to the common intake transaction ticket format the seconditem of financial transaction information.

In some embodiments, the one or more receiving modules, such astransaction intake module 324, include a single stack applicationprogram interface residing on one of the one or more servers that hostor comprise electronic commerce management module 320. In someembodiments, a server communicates remotely with the mobile computingdevice over a wireless network. In some embodiments, the servercommunicates remotely with the merchant-facing point of sale device overa second network. In some embodiments, the receiving the first item offinancial transaction information from the customer-facing interfacefurther includes receiving in the common intake transaction ticketformat at the single stack application interface from the mobilecomputing device the first item of financial transaction informationfrom the customer-facing interface. In some embodiments, the receivingthe second item of financial transaction information from themerchant-facing point-of-sale interface further includes receiving inthe common intake transaction ticket format at the single stackapplication interface the second item of financial transactioninformation from the merchant-facing point-of-sale interface.

In some embodiments, the transaction execution module, such as financialexecution module 334, is further configured for receiving on the one ormore servers a transaction authorization confirmation from the firstexternal financial party, and the point of sale server is furtherconfigured for transmitting to the customer-facing interface anindication of the transaction authorization confirmation. In someembodiments, the payment processing module, such as financial executionmodule 334, includes a payment processing gateway for communicating withservers of external financial processors using encrypted links over anetwork.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms further includes a businessintelligence analytics module 328 for providing business intelligencebased at least in part on the first item of financial transactioninformation. In some embodiments, such business intelligence includesrisk assessment for use in deciding whether to authorize or denyauthorization for a transaction.

In some embodiments, the system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms further includes an inventorycoordination module 326 for providing transaction fulfillmentinformation based at least in part on the first item of financialtransaction information. In some embodiments, the inventory coordinationmodule 326 enables the integrated electronic commerce module 320 tomonitor consolidated stock levels and determine when to re-order,without relying on additional systems or manual reporting, therebyenabling merchants to provide a consistent, seamless experience forconsumers across all channels, including offering returns through anychannel no matter where the purchase originated.

In some embodiments, the financial execution module 334 supportsreconciling accounts for every channel, such that merchants mayconsolidate accounts with payment processors and accounting systems,without manual posting of entries.

Some embodiments of electronic commerce management module 320 support amerchant that operates a physical store, operates an online store,accepts payments on a mobile device, or any combination of thosechannels. Some embodiments of electronic commerce management module 320present a single merchant account to reduce reconciliation andaccounting headaches and to provide one version of the data throughconsolidated reports across all channels and touchpoints. Someembodiments of electronic commerce management module 320 can also handlethe issues of managing inventory across mobile and e-commercetouchpoints, as well as in the store, providing a single view of themerchandise that's available to sell, and helping businesses balancebetween inventory and demand.

Some embodiments of electronic commerce management module 320 support acloud-based point-of-sale, mobile and eCommerce framework thatintegrates payments with inventory management.

Some embodiments of electronic commerce management module 320 real-time,in-app inventory tracking, management and replenishment directly from amobile application. Some embodiments of electronic commerce managementmodule 320 provide import and export capabilities that allow merchantsto easily transfer and integrate inventory data into other systems. Someembodiments of electronic commerce management module 320 provideIntegration with third party eCommerce platforms—sales and inventorydata by location provides merchants more valuable insights into theirbusiness. Some embodiments of electronic commerce management module 320provide the ability to set replenishment thresholds and alerts andtransfer inventory between locations and channels. Some embodiments ofelectronic commerce management module 320 adjust inventory for sales andreturns in real-time and can also work with a merchant's existinginventory platform, by allowing merchants to integrate in to someembodiments of electronic commerce management module 320 usingapplication program interfaces.

Some embodiments of electronic commerce management module 320 can alsosolve the problems of the friction points mentioned above by eliminatingdisparate payment processors and processing rates, further simplifyingreconciliation across all of a merchant's selling channels. In moving toa single payments provider under some embodiments, merchants can alsotake advantage of volume pricing, and get the best possible rates foreach channel.

Some embodiments of electronic commerce management module 320 providebusiness insights, such merchants can leverage data to optimize sales,for example such as how much floor space to allocate to specificproducts, what items and locations provide the most revenue and profitand what products to feature. Merchants also have the ability to storecustomer history, past purchases and other customer-specific data tohelp them become more customer-centric. These systems open the door tointegrated loyalty programs and other customer relationship managementtools to help merchants know who their best customers are and how tobest reach them how, when and where the customer wants to shop.

Some embodiments of electronic commerce management module 320 also allowdevelopers to integrate payments, inventory and business insights intotheir platforms through the only single stack of application programinterfaces for card present and card not present transactions.

In some embodiments, the synchronization server module 336 implements asynchronization server protocol that synchronizes data between a server,such as one of the one or more servers that host or comprise electroniccommerce management module 320, and clients, such as ordering customerclient 110 or merchant client 120 of FIG. 1, providing objects fromdatabase 102 of FIG. 1 from storage medium 340 that the clients have notreceived or that have been updated since client receipt.

In some embodiments, data synchronization from synchronization servermodule 336 allows clients to execute transactions or parts oftransactions offline without querying one of the one or more serversthat host or comprise electronic commerce management module 320, insteadusing local copies of objects from database 102 of FIG. 1. In someembodiments, database objects stored in storage medium 340 includeserial numbers, and based on the serial number, and the fact thatclients store a serial number (called an update ID) for their mostrecent transaction update, clients may send to one of the one or moreservers that host or comprise electronic commerce management module 320a database-wide pointer indicating the client's last received object(inserted or updated) to request from synchronization server module 336.In some embodiments, serial numbers for objects stored in storage medium340 are assigned at object creation and new serial numbers are assignedat object update.

In some embodiments, synchronization server module receives a serialnumber and a list of query objects or object types of interest to theclient and replies in the background of transaction flow with an updateof all data (both new and updated) with serial numbers assigned afterthe pointer. In some embodiments, this update allows for off-peakupdates of the database outside of time-critical traffic flow. Theclient then assimilates the reply objects into a local (sometimespartial) mirror copy of the database, as well as saving the pointer ofthe last updated object for use in the next query. When the client isupdating certain objects for its own transaction, synchronization servermodule 336 also provides the updated state of the objects created orupdated by the client and sends the update ID and modified and newobjects resulting from the transaction, as well as any that may havebeen modified by another client.

FIG. 4 illustrates a module that may implement unified inventory andfinancial transaction management, according to some embodiments. Anelectronic commerce management module 420 receives as input transactionconfirmations 470, transaction tickets 410 and user input 412 (forexample, in some embodiments, through a user interface 422) and storestransaction execution orders 450, unified inventory data 430, andunified format transactions 460 in a storage medium 440. Electroniccommerce management module 420 is one embodiment of integratedelectronic commerce module 204 of FIG. 2, which is discussed above.

In some embodiments, electronic commerce management module 420 includesa transaction intake module such as a gateway application programinterface 424, an inventory coordination module 426, a synchronizationserver module 436, a financial execution module such as a paymentprocessing gateway 434, a business intelligence analytics module 428,and an advertising module 432.

In some embodiments, electronic commerce management module 420implements or supports a system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms. In some embodiments,electronic commerce management module 420 includes one or more computersconfigured to implement by executing instructions on one or moreprocessors a platform-agnostic transaction-related communication system.In some embodiments, electronic commerce management module 420 includessoftware for execution on one or more computers configured to implementby executing instructions on one or more processors a platform-agnostictransaction-related communication system. In some embodiments, thetransaction-related communication system includes one or more receivingmodules, such as gateway application program interface 424, forreceiving a first item of financial transaction information from acustomer-facing interface, such as a user interface 422, which may beimplemented on electronic commerce management module 420 or in aseparate system, and receiving a second item of financial transactioninformation from a merchant-facing point-of-sale interface.

In some embodiments, the transaction-related communication systemincludes a point of sale server 438, for example as a complement ofpayment processing gateway 434, for rendering in a common internalformat (for example, for storage on storage medium 440 as unified formattransactions 460) the first item of financial transaction informationfrom the customer-facing interface of user interface 422, and renderingin the common internal format (for example, for storage on storagemedium 440 as unified format transactions 460) the second item offinancial transaction information from the merchant-facing point-of-saleinterface. In some embodiments, the transaction-related communicationsystem includes a payment processing module, for example as a componentof payment processing gateway 434, for rendering in a second format (forexample, as transaction execution orders 450) the first item offinancial transaction information for payment processing by a firstexternal financial party, and rendering in a third format (for example,as transaction execution orders 450) the first item of financialtransaction information for payment processing by a second externalfinancial party.

In some embodiments, the transaction-related communication systemincludes a transaction execution module, for example as a component ofpayment processing gateway 434, for transmitting in the second formatthe first item of financial transaction information for paymentprocessing by the first external financial party, and transmitting inthe third format the second item of financial transaction informationfor payment processing by the second external financial party. In someembodiments, the transaction execution module supports reconcilingaccounts for every channel, such that merchants may consolidate accountswith payment processors and accounting systems, without manual postingof entries.

In some embodiments, the system uses electronic commerce managementmodule 420 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms. In some embodiments, the common internal format is acommon intake transaction ticket format, which may be used in unifiedformat transactions 460. In some embodiments, the one or more receivingmodules, such as gateway application program interface 424, include asingle stack application program interface residing on one of the one ormore servers that host or comprise electronic commerce management module420. In some embodiments, the receiving the first item of financialtransaction information, such as transaction tickets 410, from acustomer-facing interface further includes receiving in the commonintake transaction ticket format over the network from a mobilecomputing device the first item of financial transaction informationfrom the customer-facing interface, such as a user interface 422implemented on a system remote from electronic commerce managementmodule 420. In some embodiments, the receiving the second item offinancial transaction information, such as transaction tickets 410, fromthe merchant-facing point-of-sale interface further includes receivingover the network in the common intake transaction ticket format thesecond item of financial transaction information from themerchant-facing point-of-sale interface.

In some embodiments, the common internal format is a common intaketransaction ticket format for use in transaction tickets 410. In someembodiments, the system further includes a first translation module on amobile computing device, such as a user interface 422 implemented on asystem remote from electronic commerce management module 420, forreceiving from a customer facing application including thecustomer-facing interface on the mobile computing device the first itemof financial transaction information, and translating to a common intaketransaction ticket format the first item of financial transactioninformation. In some embodiments, the system further includes a secondtranslation module on a merchant-facing point of sale device forreceiving from a merchant facing application including themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, andtranslating to the common intake transaction ticket format the seconditem of financial transaction information.

In some embodiments, the one or more receiving modules, such as gatewayapplication program interface 424, include a single stack applicationprogram interface residing on one of the one or more servers that hostor comprise electronic commerce management module 420. In someembodiments, a server communicates remotely with the mobile computingdevice over a wireless network. In some embodiments, the servercommunicates remotely with the merchant-facing point of sale device overa second network. In some embodiments, the receiving the first item offinancial transaction information from the customer-facing interfacefurther includes receiving in the common intake transaction ticketformat at the single stack application interface from the mobilecomputing device the first item of financial transaction informationfrom the customer-facing interface. In some embodiments, the receivingthe second item of financial transaction information from themerchant-facing point-of-sale interface further includes receiving inthe common intake transaction ticket format at the single stackapplication interface the second item of financial transactioninformation from the merchant-facing point-of-sale interface.

In some embodiments, the transaction execution module, such as paymentprocessing gateway 434, is further configured for receiving on the oneor more servers a transaction authorization confirmation from the firstexternal financial party, and the point of sale server is furtherconfigured for transmitting to the customer-facing interface anindication of the transaction authorization confirmation. In someembodiments, the payment processing module, such as payment processinggateway 434, includes a payment processing gateway for communicatingwith servers of external financial processors using encrypted links overa network.

In some embodiments, the inventory coordination module 426 enables theintegrated electronic commerce module 420 to monitor consolidated stocklevels and determine when to re-order, without relying on additionalsystems or manual reporting, thereby enabling merchants to provide aconsistent, seamless experience for consumers across all channels,including offering returns through any channel no matter where thepurchase originated.

Some embodiments of electronic commerce management module 420 support amerchant that operates a physical store, operates an online store,accepts payments on a mobile device, or any combination of thosechannels. Some embodiments of electronic commerce management module 420present a single merchant account to reduce reconciliation andaccounting headaches and to provide one version of the data throughconsolidated reports across all channels and touchpoints. Someembodiments of electronic commerce management module 420 can also handlethe issues of managing inventory across mobile and e-commercetouchpoints, as well as in the store, providing a single view of themerchandise that's available to sell, and helping businesses balancebetween inventory and demand.

Some embodiments of electronic commerce management module 420 support acloud-based point-of-sale, mobile and eCommerce framework thatintegrates payments with inventory management.

Some embodiments of electronic commerce management module 420 real-time,in-app inventory tracking, management and replenishment directly from amobile application. Some embodiments of electronic commerce managementmodule 420 provide import and export capabilities that allow merchantsto easily transfer and integrate inventory data into other systems. Someembodiments of electronic commerce management module 420 provideIntegration with third party eCommerce platforms—sales and inventorydata by location provides merchants more valuable insights into theirbusiness. Some embodiments of electronic commerce management module 420provide the ability to set replenishment thresholds and alerts andtransfer inventory between locations and channels. Some embodiments ofelectronic commerce management module 420 adjust inventory for sales andreturns in real-time and can also work with a merchant's existinginventory platform, by allowing merchants to integrate in to someembodiments of electronic commerce management module 420 usingapplication program interfaces.

Some embodiments of electronic commerce management module 420 can alsosolve the problems of the friction points mentioned above by eliminatingdisparate payment processors and processing rates, further simplifyingreconciliation across all of a merchant's selling channels. In moving toa single payments provider under some embodiments, merchants can alsotake advantage of volume pricing, and get the best possible rates foreach channel.

Some embodiments of electronic commerce management module 420 providebusiness insights, such merchants can leverage data to optimize sales,for example such as how much floor space to allocate to specificproducts, what items and locations provide the most revenue and profitand what products to feature. Merchants also have the ability to storecustomer history, past purchases and other customer-specific data tohelp them become more customer-centric. These systems open the door tointegrated loyalty programs and other customer relationship managementtools to help merchants know who their best customers are and how tobest reach them how, when and where the customer wants to shop.

Some embodiments of electronic commerce management module 420 also allowdevelopers to integrate payments, inventory and business insights intotheir platforms through the only single stack of application programinterfaces for card present and card not present transactions.

FIG. 5 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. Responsive to anorder from a customer, the order from the customer is deconstructed intoa financial transaction and an inventory transaction (block 500). Thefinancial transaction is translated into a unified format (block 502).An inventory transaction is translated into the unified format (block504). The transaction is posted (block 506). Business intelligenceanalytics data is generated from the transaction data (block 508).

FIG. 6 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. Order data andpayment data are received at user-facing payment interface (block 600).A transaction ticket is generated (block 602). The transaction ticket istransmitted to a point of sale server for processing (block 604).Confirmation is received (block 606). Confirmation is displayed (block608).

FIG. 7 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. Order data andpayment data are received to a merchant-facing mobile application (block700). A transaction ticket is generated (block 702). The transactionticket is transmitted to a point of sale server for processing (block704). Confirmation is received (block 706). Confirmation is displayed(block 708).

FIG. 8 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. A ticket isreceived at a point of sale server (block 800). A payment processinggateway is called (block 802). Payment data is sent to the paymentgateway using the gateway application programming interface (block 804).Data is formatted for common database storage (block 806). Response isreceived from the payment gateway (block 808). Data is committed to thedatabase (block 810). Inventory is adjusted and the inventory cloud isupdated (block 812). Confirmation is sent (block 814). The transactionis posted to point of sale listeners (block 816).

FIG. 9 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. A change order isreceived (block 900). Inventory is confirmed (block 902). The change iscommitted to the inventory database (block 904). A source is notified torelease inventory (block 906). An update is posted to inventorylisteners (block 908).

FIG. 10 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. Routing isascertained (block 1000). A merchant is authenticated (block 1002).Formatting of the transaction for a provider (payment front end) isperformed (block 1004). The transaction is sent to a provider (block1006). An authorization or decline is received (block 1008). Theauthorization or decline response is transmitted to the point-of-saleserver (block 1010).

FIG. 11 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. A first item offinancial transaction information is received from a customer-facinginterface (block 1100). A second item of financial transactioninformation is received from a merchant-facing point-of-sale interface(block 1102). The first item of financial transaction information fromthe customer-facing interface is rendered in a common internal format(block 1104). The second item of financial transaction information fromthe merchant-facing point-of-sale interface is rendered in the commoninternal format (block 1106). A first item of financial transactioninformation for payment processing by a second external financial partyis rendered in a third format (block 1108). The first item of financialtransaction information is transmitted in the third format for paymentprocessing by the first external financial party (block 1110). Thesecond item of financial transaction information is transmitted in thethird format for payment processing by the second external financialparty (block 1112).

FIG. 12 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. A first item offinancial transaction information is received from a customer facingapplication including a customer-facing interface on the mobilecomputing device (block 1200). A second item of financial transactioninformation is received from a merchant facing application including themerchant-facing point-of-sale interface on a merchant point of saledevice (block 1202). The first item of financial transaction informationis translated to a common intake transaction ticket format (block 1204).The second item of financial transaction information is translated tothe common intake transaction ticket format (block 1206).

FIG. 13 is a flowchart of a process for unified inventory and financialtransaction management, according to some embodiments. A transactionauthorization confirmation from the first external financial party isreceived on one or more servers (block 1300). An indication of thetransaction authorization confirmation is transmitted to thecustomer-facing interface (block 1302).

FIG. 14 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 15 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 16 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 17 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 18 is a user interface for creating a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 19 is a user interface for selecting for review a sales ticket forunified inventory and financial transaction management, according tosome embodiments.

FIG. 20 is a user interface for reviewing a sales ticket for unifiedinventory and financial transaction management, according to someembodiments.

FIG. 21 is a user interface for selecting for review an item in a salesticket for unified inventory and financial transaction management,according to some embodiments.

FIG. 22 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 23 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 24 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 25 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 26 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 27 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 28 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 29 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 30 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 31 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 32 is a user interface for reviewing an overview of inventory in asystem for unified inventory and financial transaction management,according to some embodiments.

FIG. 33 is a user interface for reviewing an overview of transactions ina system for unified inventory and financial transaction management,according to some embodiments.

FIG. 34 is a user interface for recording a transaction in a system forunified inventory and financial transaction management, according tosome embodiments.

FIG. 35 is a user interface for reporting a transaction in a system forunified inventory and financial transaction management, according tosome embodiments.

FIG. 36 is a flowchart of a synchronization method for unified inventoryand financial transaction management, according to some embodiments. Apointer for a serial number indicating a last updated object received isreceived from the client (block 3600). A list of objects or object typesfor update is received (block 3602). Subsequent objects are transmitted(block 3604).

Example System

Embodiments of an electronic commerce management module and/or of theproduction resources management techniques as described herein may beexecuted on one or more computer systems, which may interact withvarious other devices. One such computer system is illustrated by FIG.37. In different embodiments, computer system 3700 may be any of varioustypes of devices, including, but not limited to, a personal computersystem, desktop computer, laptop, notebook, or netbook computer,mainframe computer system, handheld computer, workstation, networkcomputer, a camera, a set top box, a mobile device, a consumer device,video game console, handheld video game device, application server,storage device, a peripheral device such as a switch, modem, router, orin general any type of computing or electronic device.

In the illustrated embodiment, computer system 3700 includes one or moreprocessors 3710 coupled to a system memory 3720 via an input/output(I/O) interface 3730. Computer system 3700 further includes a networkinterface 3740 coupled to I/O interface 3730, and one or moreinput/output devices 3750, such as cursor control device 3760, keyboard3770, and display(s) 3780. In some embodiments, it is contemplated thatembodiments may be implemented using a single instance of computersystem 3700, while in other embodiments multiple such systems, ormultiple nodes making up computer system 3700, may be configured to hostdifferent portions or instances of embodiments. For example, in oneembodiment some elements may be implemented via one or more nodes ofcomputer system 3700 that are distinct from those nodes implementingother elements.

In various embodiments, computer system 3700 may be a uniprocessorsystem including one processor 3710, or a multiprocessor systemincluding several processors 3710 (e.g., two, four, eight, or anothersuitable number). Processors 3710 may be any suitable processor capableof executing instructions. For example, in various embodiments,processors 3710 may be general-purpose or embedded processorsimplementing any of a variety of instruction set architectures (ISAs),such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitableISA. In multiprocessor systems, each of processors 3710 may commonly,but not necessarily, implement the same ISA.

In some embodiments, at least one processor 3710 may be a graphicsprocessing unit. A graphics processing unit or GPU may be considered adedicated graphics-rendering device for a personal computer,workstation, game console or other computing or electronic device.Modern GPUs may be very efficient at manipulating and displayingcomputer graphics, and their highly parallel structure may make themmore effective than typical CPUs for a range of complex graphicalalgorithms. For example, a graphics processor may implement a number ofgraphics primitive operations in a way that makes executing them muchfaster than drawing directly to the screen with a host centralprocessing unit (CPU). In various embodiments, the image processingmethods disclosed herein may, at least in part, be implemented byprogram instructions configured for execution on one of, or parallelexecution on two or more of, such GPUs. The GPU(s) may implement one ormore application programmer interfaces (APIs) that permit programmers toinvoke the functionality of the GPU(s). Suitable GPUs may becommercially available from vendors such as NVIDIA Corporation, ATITechnologies (AMD), and others.

System memory 3720 may be configured to store program instructionsand/or data accessible by processor 3710. In various embodiments, systemmemory 3720 may be implemented using any suitable memory technology,such as static random access memory (SRAM), synchronous dynamic RAM(SDRAM), nonvolatile/Flash-type memory, or any other type of memory. Inthe illustrated embodiment, program instructions and data implementingdesired functions, such as those described above for embodiments of aelectronic commerce management module are shown stored within systemmemory 3720 as program instructions 3725 and data storage 3735,respectively. In other embodiments, program instructions and/or data maybe received, sent or stored upon different types of computer-accessiblemedia or on similar media separate from system memory 3720 or computersystem 3700. Generally speaking, a computer-accessible medium mayinclude storage media or memory media such as magnetic or optical media,e.g., disk or CD/DVD-ROM coupled to computer system 3700 via I/Ointerface 3730. Program instructions and data stored via acomputer-accessible medium may be transmitted by transmission media orsignals such as electrical, electromagnetic, or digital signals, whichmay be conveyed via a communication medium such as a network and/or awireless link, such as may be implemented via network interface 3740.

In one embodiment, I/O interface 3730 may be configured to coordinateI/O traffic between processor 3710, system memory 3720, and anyperipheral devices in the device, including network interface 3740 orother peripheral interfaces, such as input/output devices 3750. In someembodiments, I/O interface 3730 may perform any necessary protocol,timing or other data transformations to convert data signals from onecomponent (e.g., system memory 3720) into a format suitable for use byanother component (e.g., processor 3710). In some embodiments, I/Ointerface 3730 may include support for devices attached through varioustypes of peripheral buses, such as a variant of the Peripheral ComponentInterconnect (PCI) bus standard or the Universal Serial Bus (USB)standard, for example. In some embodiments, the function of I/Ointerface 3730 may be split into two or more separate components, suchas a north bridge and a south bridge, for example. In addition, in someembodiments some or all of the functionality of I/O interface 3730, suchas an interface to system memory 3720, may be incorporated directly intoprocessor 3710.

Network interface 3740 may be configured to allow data to be exchangedbetween computer system 3700 and other devices attached to a network,such as other computer systems, or between nodes of computer system3700. In various embodiments, network interface 3740 may supportcommunication via wired or wireless general data networks, such as anysuitable type of Ethernet network, for example; viatelecommunications/telephony networks such as analog voice networks ordigital fiber communications networks; via storage area networks such asFibre Channel SANs, or via any other suitable type of network and/orprotocol.

Input/output devices 3750 may, in some embodiments, include one or moredisplay terminals, keyboards, keypads, touchpads, scanning devices,voice or optical recognition devices, or any other devices suitable forentering or retrieving data by one or more computer system 3700.Multiple input/output devices 3750 may be present in computer system3700 or may be distributed on various nodes of computer system 3700. Insome embodiments, similar input/output devices may be separate fromcomputer system 3700 and may interact with one or more nodes of computersystem 3700 through a wired or wireless connection, such as over networkinterface 3740.

As shown in FIG. 8, memory 3720 may include program instructions 3725,configured to implement embodiments of a electronic commerce managementmodule as described herein, and data storage 3735, comprising variousdata accessible by program instructions 3725. In one embodiment, programinstructions 3725 may include software elements of embodiments of aelectronic commerce management module as illustrated in the aboveFigures. Data storage 3735 may include data that may be used inembodiments. In other embodiments, other or different software elementsand data may be included.

Those skilled in the art will appreciate that computer system 3700 ismerely illustrative and is not intended to limit the scope of aelectronic commerce management module as described herein. Inparticular, the computer system and devices may include any combinationof hardware or software that can perform the indicated functions,including a computer, personal computer system, desktop computer,laptop, notebook, or netbook computer, mainframe computer system,handheld computer, workstation, network computer, a camera, a set topbox, a mobile device, network device, internet appliance, PDA, wirelessphones, pagers, a consumer device, video game console, handheld videogame device, application server, storage device, a peripheral devicesuch as a switch, modem, router, or in general any type of computing orelectronic device. Computer system 3700 may also be connected to otherdevices that are not illustrated, or instead may operate as astand-alone system. In addition, the functionality provided by theillustrated components may in some embodiments be combined in fewercomponents or distributed in additional components. Similarly, in someembodiments, the functionality of some of the illustrated components maynot be provided and/or other additional functionality may be available.

Those skilled in the art will also appreciate that, while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 3700 may be transmitted to computer system3700 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network and/or a wireless link. Various embodiments mayfurther include receiving, sending or storing instructions and/or dataimplemented in accordance with the foregoing description upon acomputer-accessible medium. Accordingly, the present invention may bepracticed with other computer system configurations.

CONCLUSION

Various embodiments may further include receiving, sending or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer-accessible medium. Generally speaking, acomputer-accessible medium may include storage media or memory mediasuch as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.),ROM, etc., as well as transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as network and/or a wireless link.

The various methods as illustrated in the Figures and described hereinrepresent example embodiments of methods. The methods may be implementedin software, hardware, or a combination thereof The order of method maybe changed, and various elements may be added, reordered, combined,omitted, modified, etc.

Various modifications and changes may be made as would be obvious to aperson skilled in the art having the benefit of this disclosure. It isintended that the invention embrace all such modifications and changesand, accordingly, the above description to be regarded in anillustrative rather than a restrictive sense.

What is claimed is:
 1. A system for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms, the system comprising: one ormore computers configured to implement by executing instructions on oneor more processors a platform-agnostic transaction-related communicationsystem, wherein the transaction-related communication system comprises:one or more receiving modules for receiving a first item of financialtransaction information from a customer-facing interface, and receivinga second item of financial transaction information from amerchant-facing point-of-sale interface, a point of sale server forrendering in a common internal format the first item of financialtransaction information from the customer-facing interface, andrendering in the common internal format the second item of financialtransaction information from the merchant-facing point-of-saleinterface, a payment processing module for rendering in a second formatthe first item of financial transaction information for paymentprocessing by a first external financial party, and rendering in a thirdformat the first item of financial transaction information for paymentprocessing by a second external financial party, and a transactionexecution module for transmitting in the second format the first item offinancial transaction information for payment processing by the firstexternal financial party, and transmitting in the third format thesecond item of financial transaction information for payment processingby the second external financial party.
 2. The system of claim 1 forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, wherein the common internal format is a common intaketransaction ticket format, the one or more receiving modules comprise asingle stack application program interface residing on one of the one ormore servers, the receiving the first item of financial transactioninformation from the customer-facing interface further comprisesreceiving in the common intake transaction ticket format over thenetwork from a mobile computing device the first item of financialtransaction information from the customer-facing interface, and thereceiving the second item of financial transaction information from themerchant-facing point-of-sale interface further comprises receiving overthe network in the common intake transaction ticket format the seconditem of financial transaction information from the merchant-facingpoint-of-sale interface.
 3. The system of claim 1 for providing paymentprocessing services from a plurality of disparate payment processors toa plurality of disparate transaction intake platforms, wherein thecommon internal format is a common intake transaction ticket format, thesystem further comprises a first translation module on a mobilecomputing device for receiving from a customer facing applicationcomprising the customer-facing interface on the mobile computing devicethe first item of financial transaction information, and translating toa common intake transaction ticket format the first item of financialtransaction information, and the system further comprises a secondtranslation module on a merchant-facing point of sale device forreceiving from a merchant facing application comprising themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, andtranslating to the common intake transaction ticket format the seconditem of financial transaction information.
 4. The system of claim 3 forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, wherein the one or more receiving modules comprise a singlestack application program interface residing on one of the one or moreservers, the server communicates remotely with the mobile computingdevice over a wireless network, the server communicates remotely withthe merchant-facing point of sale device over a second network, thereceiving the first item of financial transaction information from thecustomer-facing interface further comprises receiving in the commonintake transaction ticket format at the single stack applicationinterface from the mobile computing device the first item of financialtransaction information from the customer-facing interface, and thereceiving the second item of financial transaction information from themerchant-facing point-of-sale interface further comprises receiving inthe common intake transaction ticket format at the single stackapplication interface the second item of financial transactioninformation from the merchant-facing point-of-sale interface.
 5. Thesystem of claim 1 for providing payment processing services from aplurality of disparate payment processors to a plurality of disparatetransaction intake platforms, wherein the transaction execution moduleis further configured for receiving on the one or more servers atransaction authorization confirmation from the first external financialparty, and the point of sale server is further configured fortransmitting to the customer-facing interface an indication of thetransaction authorization confirmation.
 6. The system of claim 1 forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, wherein the payment processing module comprises a paymentprocessing gateway for communicating with servers of external financialprocessors using encrypted links over a network.
 7. The system of claim1 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms, further comprising: a business intelligence analyticsmodule for providing business intelligence based at least in part on thefirst item of financial transaction information.
 8. The system of claim1 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms, further comprising: an inventory coordination modulefor providing transaction fulfillment information based at least in parton the first item of financial transaction information.
 9. A method forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, the method comprising: one or more computers executinginstructions on one or more processors a platform-agnostictransaction-related communication system to perform receiving a firstitem of financial transaction information from a customer-facinginterface; receiving a second item of financial transaction informationfrom a merchant-facing point-of-sale interface; rendering in a commoninternal format the first item of financial transaction information fromthe customer-facing interface; rendering in the common internal formatthe second item of financial transaction information from themerchant-facing point-of-sale interface; rendering in a second formatthe first item of financial transaction information for paymentprocessing by a first external financial party; rendering in a thirdformat the first item of financial transaction information for paymentprocessing by a second external financial party; transmitting in thesecond format the first item of financial transaction information forpayment processing by the first external financial party; andtransmitting in the third format the second item of financialtransaction information for payment processing by the second externalfinancial party.
 10. The method of claim 9 for providing paymentprocessing services from a plurality of disparate payment processors toa plurality of disparate transaction intake platforms, wherein thecommon internal format is a common intake transaction ticket format, thereceiving the first item of financial transaction information from thecustomer-facing interface further comprises receiving in the commonintake transaction ticket format over the network from a mobilecomputing device the first item of financial transaction informationfrom the customer-facing interface, and the receiving the second item offinancial transaction information from the merchant-facing point-of-saleinterface further comprises receiving over the network in the commonintake transaction ticket format the second item of financialtransaction information from the merchant-facing point-of-saleinterface.
 11. The method of claim 9 for providing payment processingservices from a plurality of disparate payment processors to a pluralityof disparate transaction intake platforms, wherein the common internalformat is a common intake transaction ticket format, and the methodfurther comprises: receiving from a customer facing applicationcomprising the customer-facing interface on the mobile computing devicethe first item of financial transaction information, translating to acommon intake transaction ticket format the first item of financialtransaction information, and receiving from a merchant facingapplication comprising the merchant-facing point-of-sale interface on amerchant point of sale device the second item of financial transactioninformation, and translating to the common intake transaction ticketformat the second item of financial transaction information.
 12. Themethod of claim 11 for providing payment processing services from aplurality of disparate payment processors to a plurality of disparatetransaction intake platforms, wherein the receiving the first item offinancial transaction information from the customer-facing interfacefurther comprises receiving in the common intake transaction ticketformat at a single stack application interface from the mobile computingdevice the first item of financial transaction information from thecustomer-facing interface, and the receiving the second item offinancial transaction information from the merchant-facing point-of-saleinterface further comprises receiving in the common intake transactionticket format at the single stack application interface the second itemof financial transaction information from the merchant-facingpoint-of-sale interface.
 13. The method of claim 9 for providing paymentprocessing services from a plurality of disparate payment processors toa plurality of disparate transaction intake platforms, furthercomprising receiving on the one or more servers a transactionauthorization confirmation from the first external financial party, andtransmitting to the customer-facing interface an indication of thetransaction authorization confirmation.
 14. The method of claim 9 forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, wherein the method further comprises a payment processinggateway communicating with servers of external financial processorsusing encrypted links over a network.
 15. The method of claim 9 forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, further comprising: a business intelligence analytics moduleproviding business intelligence based at least in part on the first itemof financial transaction information.
 16. The method of claim 9 forproviding payment processing services from a plurality of disparatepayment processors to a plurality of disparate transaction intakeplatforms, further comprising: an inventory coordination moduleproviding transaction fulfillment information based at least in part onthe first item of financial transaction information.
 17. Anon-transitory computer-readable storage medium storing programinstructions for providing payment processing services from a pluralityof disparate payment processors to a plurality of disparate transactionintake platforms, wherein the program instructions arecomputer-executable to implement: receiving a first item of financialtransaction information from a customer-facing interface; receiving asecond item of financial transaction information from a merchant-facingpoint-of-sale interface; rendering in a common internal format the firstitem of financial transaction information from the customer-facinginterface; rendering in the common internal format the second item offinancial transaction information from the merchant-facing point-of-saleinterface; transmitting in a second format the first item of financialtransaction information for payment processing by the first externalfinancial party; and transmitting in a third format the second item offinancial transaction information for payment processing by the secondexternal financial party.
 18. The non-transitory computer-readablestorage medium storing program instructions of claim 17 for providingpayment processing services from a plurality of disparate paymentprocessors to a plurality of disparate transaction intake platforms,wherein the common internal format is a common intake transaction ticketformat, the program instructions computer-executable to implementreceiving the first item of financial transaction information from thecustomer-facing interface further comprise program instructionscomputer-executable to implement receiving in the common intaketransaction ticket format over the network from a mobile computingdevice the first item of financial transaction information from thecustomer-facing interface, and the program instructionscomputer-executable to implement receiving the second item of financialtransaction information from the merchant-facing point-of-sale interfacefurther comprise program instructions computer-executable to implementreceiving over the network in the common intake transaction ticketformat the second item of financial transaction information from themerchant-facing point-of-sale interface.
 19. The non-transitorycomputer-readable storage medium storing program instructions of claim17 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms, wherein the common internal format is a common intaketransaction ticket format, and the program instructionscomputer-executable to implement further comprise: program instructionscomputer-executable to implement receiving from a customer facingapplication comprising the customer-facing interface on the mobilecomputing device the first item of financial transaction information,program instructions computer-executable to implement translating to acommon intake transaction ticket format the first item of financialtransaction information, and program instructions computer-executable toimplement receiving from a merchant facing application comprising themerchant-facing point-of-sale interface on a merchant point of saledevice the second item of financial transaction information, and programinstructions computer-executable to implement translating to the commonintake transaction ticket format the second item of financialtransaction information.
 20. The non-transitory computer-readablestorage medium storing program instructions of claim 19 for providingpayment processing services from a plurality of disparate paymentprocessors to a plurality of disparate transaction intake platforms,wherein the one or more receiving modules comprise a single stackapplication program interface residing on one of the one or moreservers, the program instructions computer-executable to implementreceiving the first item of financial transaction information from thecustomer-facing interface further comprise program instructionscomputer-executable to implement receiving in the common intaketransaction ticket format at the single stack application interface fromthe mobile computing device the first item of financial transactioninformation from the customer-facing interface, and the programinstructions computer-executable to implement receiving the second itemof financial transaction information from the merchant-facingpoint-of-sale interface further comprise program instructionscomputer-executable to implement receiving in the common intaketransaction ticket format at the single stack application interface thesecond item of financial transaction information from themerchant-facing point-of-sale interface.
 21. The non-transitorycomputer-readable storage medium storing program instructions of claim17 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms, further comprising program instructionscomputer-executable to implement receiving on the one or more servers atransaction authorization confirmation from the first external financialparty, and program instructions computer-executable to implementtransmitting to the customer-facing interface an indication of thetransaction authorization confirmation.
 22. The non-transitorycomputer-readable storage medium storing program instructions of claim17 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms, further comprising program instructionscomputer-executable to implement a payment processing gateway forcommunicating with servers of external financial processors usingencrypted links over a network.
 23. The non-transitory computer-readablestorage medium storing program instructions of claim 17 for providingpayment processing services from a plurality of disparate paymentprocessors to a plurality of disparate transaction intake platforms,further comprising: program instructions computer-executable toimplement a business intelligence analytics module for providingbusiness intelligence based at least in part on the first item offinancial transaction information.
 24. The non-transitorycomputer-readable storage medium storing program instructions of claim17 for providing payment processing services from a plurality ofdisparate payment processors to a plurality of disparate transactionintake platforms, further comprising: program instructionscomputer-executable to implement an inventory coordination module fortransaction fulfillment information based at least in part on the firstitem of financial transaction information.